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Response to Arguments 

1 . Applicant's arguments regarding claims 21 and 26, filed on 9/16/2008 
have been fully considered but they are not persuasive. Applicant argued for 
claims 21 and 26 that the reference of Katseff does not disclose the limitation of: 
"at least one of a data transferring unit and a data receiving unit which selectively 
reconfigures a data packet, which was previously configured, to be transferred 
according to specific information included in a header of the data packet". That is, 
Katseff always performs the converting process for the data packet to be 
transmitted regardless of the type of the data packet, but in contrast, the data 
packets of the claimed invention are selectively reconfigured according to 
information included in the header of the packet, however the Examiner 
respectfully disagrees. Based on the broadest reasonable interpretation of the 
term "selectively", the reference of Katseff does selectively perform conversion 
(TCP to UDP) when the incoming packet is detected to be TCP format, or 
selectively perform conversion (UDP to TCP) when the incoming packet is 
detected to be UDP format. Thus, the applicant's argued is moot in view of 
reference of Katseff. 

2. Applicant's arguments with respect to claims 1 , 8 and 19 have been 
considered but are moot in view of the new ground(s) of rejection. 
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Claim Rejections - 35 USC § 102 

3. The following is a quotation of the appropriate paragraphs of 35 
U.S.C. 102 that form the basis for the rejections under this section made in this 
Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1 ) an application for patent, published under section 
1 22(b), by another filed in the United States before the invention by the applicant for patent or 
(2) a patent granted on an application for patent by another filed in the United States before 
the invention by the applicant for patent, except that an international application filed under 
the treaty defined in section 351 (a) shall have the effects for purposes of this subsection of an 
application filed in the United States only if the international application designated the United 
States and was published under Article 21(2) of such treaty in the English language. 

4. Claims 1,8,19 are rejected under 35 U.S.C. 102(e) as being anticipated by 
Miller et al. (Pub 2005/01 0001 6). 

For claim 1 , Miller et al. disclosed the method of an adaptation unit 
(server) which selectively performs a first transmission mode in which a data 
packet is transferred without reconfiguration of the transmitted data packet which 
was previously configured (see paragraph 0020, 0021, 0022, and 0048-0055, fig. 
4). Referring to fig. 4, for the destination addresses in the packet that require 
conversion (step 140), the packet is converted from a sender format to a receiver 
format for each destination address that requires conversion (step 150) and then 
forwarded in accordance with the forwarding table (step 160). The received 
packet is also forwarded to those destination addresses not requiring conversion 
(steps 140 and 160), wherein the steps 140 and 160 are considered to be the 
first mode; and 

a second transmission mode in which the transmitted data packet is 
transferred after reconfiguration thereof, according to specific information 
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included in a header of the transmitted data packet (see paragraph 0020, 0021, 
0022, and 0048-0055, fig. 4). When a packet is received (step 100), a 
predetermined parameter in the packet is checked to determine if it has a value 
stored in it (that is, does the packet have any information in that field relating to a 
multicast announce address), wherein the parameter/information can be provided 
in the packet header (see paragraph 0021). Next, the packet is checked to 
determine whether any destination addresses in the packet require conversion to 
a format different from the format with which the packet was sent. For the 
destination addresses in the packet that require conversion (step 140), the 
packet is converted from a sender format to a receiver format for each 
destination address that requires conversion (step 150) and then forwarded in 
accordance with the forwarding table (step 160). Thus, the steps 140, 150 and 
160 are considered to be the second mode. 

Claim 8 is rejected similar to claim 1 . 

Claim 19 is rejected similar to claim 1 . 

Claim Rejections - 35 USC § 102 

5. The following is a quotation of the appropriate paragraphs of 35 
U.S.C. 102 that form the basis for the rejections under this section made in this 
Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in 
public use or on sale in this country, more than one year prior to the date of application for patent in 
the United States. 
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Claims 21, 22, 25-29 are rejected under 35 U.S.C. 102(b) as being 
anticipated by Katseff et al. (Pub No.: 2001/0009554). 

For claim 21, Katseff et al. disclosed a data receiving unit which 
selectively reconfigures a data packet which was previously configured, to be 
transferred according to specific information included in a header of the data 
packet (Katseff et al. paragraphs 0023, fig. 2 and fig. 3). Client A, C, and E each 
transmit a stream of digital packets to the protocol converter 48 using TCP 
format. Each packet transmitted by the clients A, C, and E contains header 
information in TCP format which is initially configured. The TCP/UDP protocol 
header converter 68 removes the TCP header information from the packets, and 
translates the TCP header to UDP header, and adds the UDP header to the 
packets, and thus the packets are transmitted after the reconfiguration from TCP 
to UDP in the header; wherein said at least one of the data transferring unit and 
the receiving unit reconfigures the data packet by removing header information of 
the data packet to create new packet information and adding additional data 
thereto (Katseff et al. paragraphs 0023, fig. 2 and fig. 3). The TCP/UDP protocol 
header converter 68 removes the TCP header information from the packets, and 
translates the TCP to UDP header. 

Regarding claim 22, Katseff et al. disclosed the feature wherein in 
response to the data packet received thereto being the reconfigured data packet, 
said at least one of the transferring unit and the receiving unit restores the 
reconfigured data packet to an original data packet format (Katseff et al. 
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paragraphs 0023-0024, fig. 2 and fig. 3). The UDP/TCP converter converts the 
UDP packet back to TCP format. 

Regarding claim 25, Katseff et al. disclosed the feature wherein said at 
least one of the data transferring unit and the receiving unit comprises an 
adaptation layer which selectively reconfigures the data packet to increase a 
transmission efficiency and restores the reconfigured data packet to an original 
data packet format (Katseff et al. paragraphs 0023-0024, fig. 2 and fig. 3). The 
TCP/UDP protocol header converter 68 removes the TCP header information 
from the packets, and translates the TCP to UDP header. Then the UDP/TCP 
converter converts the UDP back to the TCP format. Wherein the UDP provides 
fast packet transmission. 

Regarding claim 26, Katseff et al. disclosed the feature of selectively 
reconfiguring the data packet according to specific information included in a 
header of the data packet, before transmitting the data packet (Katseff et al. 
paragraphs 0023, fig. 2 and fig. 3). Client A, C, and E each transmit a stream of 
digital packets to the protocol converter 48 using TCP format. Each packet 
transmitted by the clients A, C, and E contains header information in TCP format 
which is initially configured. The TCP/UDP protocol header converter 68 removes 
the TCP header information from the packets, and translates the TCP header to 
UDP header, and adds the UDP header to the packets, and thus the packets are 
transmitted after the reconfiguration from TCP to UDP in the header; 

restoring the data packet to a data packet state before being subjected to 
the reconfiguration, if the received data packet has been reconfigured (Katseff et 
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al. paragraphs 00230024, fig. 2 and fig. 3). The UDP/TCP converter converts the 
UDP packet back to TCP format. 

Regarding claim 27, Katseff et al. disclosed the feature wherein the 
reconfiguration of the data packet comprises removing header information of the 
data packet to create new packet information and adding additional data thereto 
(Katseff et al. paragraphs 0023-0024, fig. 2 and fig. 3). The converter 69 removes 
the TCP header and translates the TCP to UDP. 

Regarding claim 28, Katseff et al. disclosed the feature wherein the 
restoring of the data packet comprises restoring data included in the received 
data packet to respective data packets before being subjected to reconfiguration 
(Katseff et al. paragraphs 0023-0024, fig. 2 and fig. 3). The UDP/TCP converter 
converts the UDP packet back to TCP format. 

Regarding claim 29, Katseff et al. disclosed the feature wherein the 
restoring of the data packet further comprises combining data of the respective 
data packets with corresponding header information (Katseff et al. paragraphs 
0023-0024, fig. 2 and fig. 3). The converter 68 revmoes the TCP header 
information, and translates the TCP to UDP header information, and adds or 
combines the UDP and header to the packets. 
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Claim Rejections - 35 USC § 103 

6. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1 , 
148 USPQ 459 (1966), that are applied for establishing a background for 
determining obviousness under 35 U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at 
issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating 
obviousness or nonobviousness. 

7. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for 
all obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described 
as set forth in section 1 02 of this title, if the differences between the subject matter sought to 
be patented and the prior art are such that the subject matter as a whole would have been 
obvious at the time the invention was made to a person having ordinary skill in the art to which 
said subject matter pertains. Patentability shall not be negatived by the manner in which the 
invention was made. 

Claims 2, 3, 6, 9, 10, 13, 15-17, 20 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Miller et al. (Pub 2005/0100016) in view of Katseff et al. 
(Pub 2001/0009554). 

For claim 2, Miller et al. did not disclose the feature wherein the unit 
selectively performs a second receiving mode in which the received data packet 
is restored to a data packet state before being subjected to the reconfiguration, 
when the received data packet is transferred in the second transmission mode. 
Katseff et al. from the same or similar fields of endeavor teaches the feature 
wherein a second receiving mode in which the received data packet is restored 
to a data packet state before being subjected to the reconfiguration, when the 
received data packet is transferred in the second transmission mode (Katseff et 
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al. paragraphs 0023-0024, fig. 2 and fig. 3). The UDP/TCP converter converts 
the UDP packet back to TCP format. Thus, it would have been obvious to the 
person of ordinary skill in the art at the time of the invention to use the feature as 
taught by Katseff et al. in the network of Miller et al. The motivation for using the 
feature being that it provides two-way transmission of data between users 
making it advantageous for applications such as Internet telephony. 

Regarding claim 3, Katseff et al. disclosed the feature wherein, in the 
second transmission mode, the adaptation unit removes header information of 
the transmitted data packet to create new packet information and adds additional 
data thereto (Katseff et al. paragraphs 0023-0024, fig. 2 and fig. 3). The 
converter 69 removes the TCP header and translates the TCP to UDP. 

Regarding claims 6, 13 Katseff et al. disclosed the feature wherein the 
transmitted data packet comprises an IP packet (Katseff et al. paragraphs 0023, 
fig. 2 and fig. 3). 

Regarding claim 9, Katseff et al. disclosed the feature of receiving of the 
data packet including selectively performing a second receiving mode in which 
the data packet is restored to a data packet state before being subjected to 
reconfiguration when the data packet is transferred through the second 
transmission mode (Katseff et al. paragraphs 0023-0024, fig. 2 and fig. 3). The 
UDP/TCP converter converts the UDP packet back to TCP format. 

Regarding claim 10, Katseff et al. disclosed the feature wherein the 
reconfiguration of the data packet comprises removing header information of the 
data packet to create new packet information and adding additional data thereto 
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(Katseff et al. paragraphs 0023-0024, fig. 2 and fig. 3). The converter 69 removes 
the TCP header and translates the TCP to UDP. 

Regarding claim 15, Katseff et al. disclosed the feature wherein in the 
second transmission mode, the adaptation unit removes header information of 
the transmitted data packet to create new packet information and adds additional 
data thereto (Katseff et al. paragraphs 0023-0024, fig. 2 and fig. 3). The 
converter 69 removes the TCP header and translates the TCP to UDP. 

Regarding claim 16, Katseff et al. disclosed the feature wherein in the 
second receiving mode, the adaptation unit restores data included in the received 
data packet to respective data packets before being subjected to reconfiguration 
(Katseff et al. paragraphs 0023-0024, fig. 2 and fig. 3). The UDP/TCP converter 
converts the UDP packet back to TCP format. 

Regarding claim 17, Katseff et al. disclosed the feature wherein in the 
second receiving mode, the adaptation unit combines the data of the respective 
data packets with corresponding header information (Katseff et al. paragraphs 
0023-0024, fig. 2 and fig. 3). The converter 68 revmoes the TCP header 
information, and translates the TCP to UDP header information, and adds or 
combines the UDP and header to the packets. 

Regarding claim 20, Katseff et al. disclosed the feature wherein the 
reconfiguration of the data packet comprises removing header information of the 
data packet to create new packet information and adding additional data thereto 
(Katseff et al. paragraphs 0023-0024, fig. 2 and fig. 3). The converter 69 removes 
the TCP header and translates the TCP to UDP. 
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8. Claims 4, 5, 7, 1 1, 12, 14, 18 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Miller et al. (Pub 2005/01 0001 6) in view of Katseff et al. 
(Pub 2001/0009554), as applied to claim 4 above, and further in view of See et 
al. (Pub 2006/0143300). 

For claims 4, 11 Miller et al. and Katseff et al. both did not explicitly 
disclose the feature wherein the new packet information comprises a destination 
service access point (DSAP), a total length of IP(lnternet Protocol), a number of 
IP headers, UDP(User Datagram Protocol) checksums, and a number of UDP 
checksums. See et al. from the same or similar fields of endeavor disclosed the 
feature wherein the new packet information comprises a destination service 
access point (DSAP), a total length of IP(lnternet Protocol), a number of IP 
headers, UDP(User Datagram Protocol) checksums, and a number of UDP 
checksums (See et al. paragraph 0065). Although Tang et al. did not disclose all 
the limitation of claim 4, however it is obvious to the person of ordinary skill in the 
art to add additional information to the packet. Thus, it would have been obvious 
to the person of ordinary skill in the art at the time of the invention to use the 
feature as taught by See et al. in the network of Miller et al. and Katseff et al. The 
motivation for using the feature being that it provides reliability in packet 
transmission system. 

Regarding claims 5, 12 See et al. disclosed the feature wherein the new 
packet information comprises four bits of the number of UDP checksums, two 
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bytes of the total length of IP, and two bytes of the UDP checksums (See et al. 
paragraph 0065). The number of bits is the design choice, which is obvious to a 
person of ordinary skill in the art. 

Regarding claims 7, 14 See et al. disclosed the feature wherein the 
specific information comprises a field of Type of Service included in the header of 
the transmitted data packet (See et al. paragraph 0065). 

Regarding claim 18 See et al. disclosed the feature wherein the new 
packet information comprises six bytes (See et al. paragraph 0065). The number 
of bits is the design choice, which is obvious to a person of ordinary skill in the 
art. 

9. Claim 23 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Katseff et al. (Pub 2001/0009554) in view of See et al. (Pub 2006/0143300). 

For claim 23, Katseff et al. did not disclose the feature wherein the new 
packet information includes a destination service access point (DSAP), a total 
length of IP, a number of IP headers, user datagram protocol (UDP) checksums, 
and a number of UDP checksums. See et al. from the same or similar fields of 
endeavor teaches the feature wherein the new packet information includes a 
destination service access point (DSAP), a total length of IP, a number of IP 
headers, user datagram protocol (UDP) checksums, and a number of UDP 
checksums (See et al. paragraph 0065). Although Tang et al. did not disclosed 
all the limitation of claim 3, however it is obvious to the person of ordinary skill in 
the art to add additional information to the packet. Thus, it would have been 
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obvious to the person of ordarinary skill in the art at the time of the invention to 
use the method as taught by See et al. in the network of Katseff et al. The 
motivation for using the method as taught by See et al. in the network 



10. Claim 24 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Katseff et al. (Pub No.: 2001/0009554) in view of Mascolo (Pub No.: 
2002/0085587). 

For claim 24, Katseff et al. did not disclose the feature wherein the data 
packet comprises audio/video (A/V) streaming data. Mascolo from the same or 
similar fields of endeavor teaches the method of the data packet comprises 
audio/video (A/V) streaming data (Mascolo paragraph 0073). Thus, it would have 
been obvious to the person of ordarinary skill in the art at the time of the 
invention to use the method as taught by Mascolo in the network of Katseff et al. 
and See et al. The motivation for using the method as taught by Mascolo in the 
network of Katseff et al. and See et al. being that it provides adaptability in the 
system. 

Examiner's Note: 

1 1 . Examiner has cited particular columns and line numbers in the references 
applied to the claims above for the convenience of the applicant. Although the 
specified citations are representative of the teachings of the art and are applied 
to specific limitations within the individual claim, other passages and figures may 
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apply as well. It is respectfully requested from the applicant in preparing 
responses, to fully consider the references in entirety as potentially teaching all 
or part of the claimed invention, as well as the context of the passage as taught 
by the prior art or disclosed by the Examiner. 

In the case of amending the claimed invention, Applicant is respectfully 
requested to indicate the portion(s) of the specification which dictate(s) the 
structure relied on for proper interpretation and also to verify and ascertain the 
metes and bounds of the claimed invention. 



Conclusion 

12. Applicant's amendment necessitated the new ground(s) of rejection 
presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. 
See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as 
set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire 
THREE MONTHS from the mailing date of this action. In the event a first reply is 
filed within TWO MONTHS of the mailing date of this final action and the advisory 
action is not mailed until after the end of the THREE-MONTH shortened statutory 
period, then the shortened statutory period will expire on the date the advisory 
action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be 
calculated from the mailing date of the advisory action. In no event, however, will 
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the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

Any inquiry concerning this communication or earlier communications from 
the examiner should be directed to KAN YUEN whose telephone number is 
(571)270-1413. The examiner can normally be reached on Monday-Friday 
1 0:00a. m-3:00p.m EST. 

If attempts to reach the examiner by telephone are unsuccessful, the 
examiner's supervisor, Ricky O. Ngo can be reached on 571-272-3139. The fax 
phone number for the organization where this application or proceeding is 
assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from 
the Patent Application Information Retrieval (PAIR) system. Status information 
for published applications may be obtained from either Private PAIR or Public 
PAIR. Status information for unpublished applications is available through 
Private PAIR only. For more information about the PAIR system, see http://pair- 
direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll- 
free). If you would like assistance from a USPTO Customer Service 
Representative or access to the automated information system, call 800-786- 
9199 (IN USA OR CANADA) or 571-272-1000. 

/Ricky Ngo/ /Kan Yuen/ 

Supervisory Patent Examiner, Art Unit 2616 Examiner, Art Unit 2416 

KY 
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